Amazon Web Services ブログ

クラウドによる FRTB コンプライアンス向けトレーディング勘定リスク管理におけるインフラストラクチャの柔軟性高度化

バーゼル規制フレームワークは、規制裁定取引を防止するために、金融機関のトレーディング勘定とバンキング勘定の厳密な区分けを目指しています。これらの規制のトレーディング勘定要素 の見直し(FRTB:トレーディング勘定に関する抜本的見直し) は、厳格なリスクモデリングを適用することと引き換えに、金融機関が資本準備金のレベルを最適化できるようにすることでトレーディングのリスク管理を強化することを目指しています。FRTB は、資本準備要件を最小限に抑える内部モデルアプローチ (IMA)、または実装が容易な標準化アプローチ (SA) といった、十分に規定されたメカニズムの 1 つを適用することでリスク管理を追求することを金融機関に求めています。バーゼル III モニタリング報告書 (2019 年 10 月) によれば、欧州の大手銀行では、全体的な必要最小資本 (MRC) が 18.6% まで上がる可能性があることを示しており、個々の銀行への影響は、SA と IMA のどちらを使用してリスク資本要件を計算するかによって左右されます。限定的な影響度調査では、SA よりも IMA を導入する方が、資本効率を最大 10% 最適化できると結論付けています。しかし、期待に反して、市場分析では IMA の採用が減少していることを示されています。SA と比較して、IMA の実装はかなり複雑で費用がかかると認識されているため、いくつかの銀行は、IMA の計算適用について十分に調査しそのメリットを定量化しています。すべての銀行が SA を採用した場合は、システムリスクの可能性があるため、規制当局は、グローバルなシステム上重要な銀行 (G-SIB) がグローバルかつ体系的に IMA を実施することを求めています。この記事では、IMA と SA のどちらを実装するかに関係なく、リスクマネージャーとトレーディングデスクの責任者が、これらの課題に対処するためにこれまでのレガシーな IT システムを超える手段を検討しなければならない理由について説明します。

FRTB に関連する課題にはどういったものがあるでしょう?必要な コンピューティングワークロードは、3~10 倍に増加すると予想されます。特殊な処理ハードウェア (FPGA、GPU など) やより高度な分散アーキテクチャを活用することで、それに対応する演算性能の向上を実現できます。しかし、これを達成するために、銀行の既存のリスクアルゴリズムは大幅なリファクタリングまたは置き換えを必要とします。この近代化アプローチを追求する必要がある金融機関もあれば、少なくとも最初は、既存のアルゴリズムを可能な限り費用対効果の高い方法で拡張する金融機関もあります。
一方、データの観点から見ると、FRTB は必要なデータ量を 10 倍に増やします。これは、新しい規制要件によりモデルストレステストの観察期間を 1 年から 10 年に拡大する必要があるためです。この履歴データは、証明が必要ないくつかのデータ品質チェックに合格する必要があります。リスクファクター適格性テスト (RFET) を満たすのに十分なコンテキストを提供するためには、既知の系統に沿った高品質の市場データが大量に必要になります。リスクファクターが RFET データ要件を満たせない場合は、モデル化が不可能なリスクファクター (NMRF) として扱う必要があります。結果の予測は、実際のトレーディングデスクの日々の P&L ポジションと一致しなければなりません。IMA 手法が調整に失敗した場合、変更された IMA モデルの検証が終わるまでトレーディングデスクの計測法を SA に戻す必要があります。これにより、トレーディングデスクの収益性が直接影響を受けます。
最終的な移行先として SA に移行する場合でも、IMA のメリットを最大限に活用するために移行する前の一時的な踏み台として移行する場合でも、いくつかの技術的課題に対処する必要があります。

  1. いかに増大するコンピューティング要件とストレージ要件に対し最適化するか?
  2.  FRTB の重要な要件であるデータ管理、品質、系統(リネージ)にどのように対応するか?
  3. 変化し続ける規制環境にトレーディング業務が適応できるようにするためのソリューションの柔軟性をいかに確保するか?

さらに、最近のように市場が極端に変動する状況においては、日中のリスク再計算が求められ、一部のシステムでは限界点を超えるケースが拡大しており、既存のオンプレミス上のリスクシステムの脆弱性が目立ちます。
オンデマンドに伸縮自在、費用対効果の優れたコンピューティングリソースに対するニーズは、かつてないほど強まっています。実際、マッキンゼー は、「必要なのは徹底的なトレーディング勘定システムのインフラストラクチャの見直しにほかならない」ことを提言しています。

データ: 費用対効果の高いストレージを実現し、品質、ガバナンス、および系統を大規模に確保
堅牢なデータ戦略は、FRTB の実装を成功させるための核心となります。しかし、必要なアプローチを迅速かつ費用対効果の優れた方法で実装するには、どうすればよいでしょうか?
FSI 組織は、すでに大量のデータをクラウドに保存し、分析しています。FINRA は、市場活動をモニタリングすることでアメリカの投資家を保護するために、米国議会の認可を受けた非営利組織であり、1 日あたり最大 1550 億件の市場イベントを Amazon Simple Storage Service (Amazon S3) に保存しています。これは、1日で最大 7 テラバイトに至る新しいデータ容量を表しています。合計すると、FINRA は 37 ペタバイトを超えるデータを保存しているため、67 兆件のレコードを超える記録をオンラインで照会できます。 Euronext は、GDPR に完全に準拠した暗号化されたデータソリューションの拡散を検討しています。ポストトレードのデータ用データレイクと 4000 億件の管理記録を AWS に移行し、1 日に 15 億件の取引関連メッセージを追加しています。一方、DTCC は AWS データインフラストラクチャを活用することで、400 万 USD の資本的支出見積を月額 903 USD に減らすことができました。
しかし、堅牢で費用対効果が高く、スケーラブルなデータインフラストラクチャを保護することは、移行の始まりにすぎません。FRTB は、銀行に対して、企業全体で実証可能なデータガバナンスと系統を確立することを求めています。データ品質、可用性 (管轄区域および製品全体にわたる)、および変更の差異について、積極的にモニタリングを行い、安全に管理する必要があります。それに応じて、AWS のお客様は、Amazon S3 を使用してデータプールを構築し、必要な組織データとメタデータ (ソース、タイムスタンプ、所有者など) を収集および選別しています。これらのデータプールは、AWS のデータ管理サービスを通じてモニタリングおよび管理できます。このサービスは、グループやその他のサービスに対して、監査可能な詳細データのアクセスコントロールを実施します。ダウンストリームアプリケーションは、AWS Glue を使用してこのデータを抽出、変換、およびロード (ETL) できます。これにより、スキーマバージョン履歴も提供され、データの変更を時間の経過とともに追跡できます。一方、AWS Transfer Family、AWS Storage Gateway、または取り込むデータ量が十分に大きい場合、AWS Snow Family のメンバーは、構造化データまたは非構造化データを使用できるメカニズムを提供します。このメカニズムでは、お客様のオンプレミスのデータストアおよびアーカイブから大規模に取り込むことができます。
金融機関は、サードパーティーのデータサービス業者から一般的なニュース、貿易、および市場情報を取り込む傾向があります。ロイター (AWS Data Exchange を使用) は、金融サービス業界の最新ニュースを含む 30 日間のニュースアーカイブ等を提供しています。 ブルームバーグ市場データフィード (B-PIPE) のプログラムを使うと、ブルームバーグターミナルと同じアセットクラスの完全なコンテンツカタログを利用できます。他のサードパーティーのデータベンダーや取引所からのデータサービスには、CME Group、FactSet、ICE Data Services、Morningstar、Refinitiv、および Xignite があります。FRTB をきっかけに、銀行間のコラボレーションも進んでいます。これらのコラボレーションは、データをプールして対象範囲を拡大し、多くのアセットをモデル化できるようにすることでNMRF の数を減らし、各市場参加者の必要資本を最小限に抑えることができます。
たとえば、CanDeal は 2019 年 2 月に DataVault Innovations を発表しました。これは、TickSmith とカナダの 6 大銀行 (BMO Nesbitt Burns Inc.、CIBC World Markets、National Bank Financial Inc.、RBC Capital Markets、Scotia Capital、および TD Securities) とのコラボレーションによるものです。DataVault は、世界初の本番環境レベルでのマルチパーティ FRTB データプールを実現し、FRTB モデル化が 400% 向上しました。このようなマルチパーティーシステムのデータ系統と制御を維持するのは通常困難です。 AWS Data Exchange では、データプロバイダーが厳選されたデータセットをキュレートし、複数のデータコンシューマーに安全に提供できるようにすることで、この課題に対処しています。データセットの内容が変更になると、新しいバージョンとしてリビジョンが作成され新しいデータセットが作成されます。その後、AWS Data Exchange プロバイダーは最新のデータを公開し、承認されたコンシューマーが利用できるようにします。これらの AWS Data Exchange メカニズムにより、データコンシューマーは使用するデータリポジトリのリビジョンを完全に制御できるため、FRTB の厳格なデータ系統要件に対応できます。

伸縮自在で多様な計算能力
AWS は、高度にスケーラブルで費用対効果の高いクラウドコンピューティングをお客様に提供しています。たとえば、米国に拠点を置くシステム上重要なグローバル銀行 (G-SIB) は、 ピーク時Amazon Elastic Cloud Compute (Amazon EC2) 100,000コアで包括的な資本分析およびレビュー (CCAR) レポートのモデルを実行しています。この銀行は、ジョブごとの計算時間を数日から数分に短縮し、以前のオンプレミスでは不可能だったモデルを実行しています。必要資本をより最適に管理することにより、銀行は数百万 USD を再配置することができました。他の顧客はさらに拡張を続けており、Western Digital の場合は、100 万台の仮想 CPU で構成される 1 つのハイパフォーマンスコンピューティング (HPC) クラスターで、250 万件を超えるシミュレーションジョブを実行しています。FRTB への対応時にはこのような演算規模拡大とコスト削減が非常に重要となります。
さらに、AWS を利用することで銀行は多くの選択肢を持つことができ、複雑なトレードオフの必要性を減らすことができます。FRTB 導入過程の各時点で、銀行は 14 種類の Amazon EC2 CPU インスタンスファミリーと 175 種の CPU インスタンスタイプから選択することで、コンピューティング集約型、メモリ集約型、AI/ML ワークロード用と各目的に合わせ、性能と費用を最適化できます。銀行は、費用対効果の高いコンピューティングリソース全体の活用つまり、既存のリスクアルゴリズムをまず最初に適用し、稼働後に最適化または代替選択肢を後から適用評価することを選択することができます。この柔軟性を実現するために、AWS 上の複数のサービスを活用できます。例えばAWS Batch は、ほとんどの銀行に馴染みのある従来のスケールアウト HPC グリッドソリューションを提供し、その他データ集約型のワークロード用の Amazon EMR、業界をリードする大規模な機械学習向けの Amazon SageMaker を提供します。
たとえば、FINRA は、AWS 分析と AI/ML サービスをサポートする 50,000 のコンピューティングノードをデプロイし、数兆件の記録に対して 1 日あたり 5,000 億件の検証チェックを実行します。一方、AWS パートナーネットワークでは、リスクアルゴリズムの最新化または代替戦略を支援するために、お客様がさまざまなモデリングアプローチを検討し、既存のシステムによって提供されるベースラインに対してパフォーマンスと正確性の両方をベンチマークできるようにサポートするサービスを提供しています。最後に、実装時間を短縮しつつ社内開発を避けたい銀行の場合、AWS パートナーネットワークからIHS Markit FRTB ソリューションスイートMurex MX.3Calypso、および SimplexFXといった FRTB ソリューション (IMA および SA) を利用できます。

ビジネスの持続可能性を実現するクラウドの俊敏性
AWS利用により大規模な初期設備投資を、お客様が使用した分に対してのみ支払う継続的な運用支出に変換することができ、最も厳しい経済状況下でも金融機関は持続可能な FRTB IMA 戦略を追求することができます。AWS のインフラストラクチャを使えば、高価なネットワーキングハードウェアや複雑な WAN ネットワークなど、通常必要となる負荷を心配することなく、このようなソリューションをグローバルに拡張できます。G-SIB は、費用対効果の高い方法で FRTB SA または IMA ソリューションを現地の規制当局が義務付けている拠点に導入し、その後現地の規制が変更されたときに、これらのソリューションを迅速に適応させることができます。このような俊敏性は、大規模な規制主導の変革に取り組む際に不可欠であるだけでなく、日常的な運用上の課題にも共通しています。リスクマネージャーとトレーディングデスクの責任者は、次のシナリオによく直面します。
現地の規制当局は、使用するリスク計測モデルの妥当性について、銀行に異議を申し立てます。この潜在的な問題を解決するには、規制当局と銀行の定量分析チームとの継続的なやり取りが必要です。修正されたリスク計測アルゴリズムが規制当局の懸念事項に対処できた後、規制当局は、過去の期間 (年単位) にわたって新しいモデルを使用して毎日の資本テストを再実行し、以前の結果と比較した差異を報告するように要求します。
従来のオンプレミス上にリスクシステムを構築している銀行は、代替が効かず既存の開発、 UAT リソースの振り替えが必要となり、新しい開発を何か月も凍結するしかありません。対照的に、AWS ベースのリスクシステムを構築している銀行は、「通常のビジネス」活動に影響を与えずに 1 つ以上の「バックテスト」環境を簡単かつ迅速に構築することができます。統合/継続的デリバリー (CI/CD) パイプラインにより、銀行の定量チームはリスクモデル調整を迅速に繰り返し、規制当局の要件に収めることができます。
結論として、FRTB 規制を遵守することが、特に現在の経済環境において課題となっています。またバーゼルのバンキング勘定規制についても、銀行のミドルオフィスで同じ技術上の課題を抱えていることにも注意が必要です。しかし、このような課題はまた、戦略的な機会を与えてくれます。金融機関は、IT システムを最新化して進化させるにつれ、初期の変革動機をはるかに超えるメリットを生み出します。クラウド導入によってもたらされる俊敏性とイノベーションは相乗的であり、組織の変化を促進し、運用効率を高め、顧客のためイノベーション加速の扉を開きます。

詳細技術に関心のある読者向けに書いた、Apache Spark と Amazon EMR を使用した FRTB 内部モデルアプローチ(IMA)の実装改善方法に関する記事では、さまざまな AWS Compute インスタンスタイプにわたって、FRTB オプションプライシングにおける古典的な Black Scholes と Longstaff Schwartz (LS) モデル使用時のパフォーマンスを比較しています。

Richard Nicholson
Richard は、アマゾン ウェブ サービス (AWS) 金融サービス EMEA のビジネスおよび市場開発チームのプリンシパルソリューションアーキテクトです。Richard は、フロントオフィスのリスクシステムアーキテクチャやバックオフィスのコアメインフレームの移行など、多様な分野に取り組んでいます。AWS に入社する前、Richard は 18 年間を自身の会社で働き、金融サービスやインダストリアル IoT を含むさまざまな業界で、ランタイムの自己適応型ソフトウェアシステムの開発と使用に注力してきました。熟練された天体物理学者である Richard は、1995 年に Salomon Brothers のインフラストラクチャシステム管理者として金融サービス業界に足を踏み入れました。

 

 

Stephan Schmidt-Tank

Stephan は、EMEA リージョンでの金融サービス業界のアマゾン ウェブ サービス (AWS) スペシャリストチームを率いています。英国/アイルランド、欧州、中東、アフリカの金融サービス業界における AWS の戦略的イニシアチブの開発と実行を主導する責任を担っています。彼は、銀行、決済、資本市場、保険業界のあらゆる顧客と協力して、既存のビジネスを変革し、AWS のサービスを活用して新しい革新的なソリューションを市場にもたらすよう支援しています。Stephan は、さまざまな組織での変革を 19 年以上進めてきた経験を持っています。AWS に入社する前は、ロンドンのバークレイズ投資銀行の運用技術部門最高執行責任者と構造改革責任者を兼任していました。また、ヨハネスブルグのバークレイズアフリカグループで首席補佐官を務め、バークレイズグループの戦略チームを率いっていました。バークレイズに入社する前は、8 年以上にわたりマッキンゼー・アンド・カンパニーのコンサルタントとして金融機関へのアドバイスを提供していました。